statically link libpq (fixes #213) #234
Conversation
|
The reason this change doesn't work in the Docker image build and Linux CI is that they don't have a package installed that delivers libpgcommon.a or libpgport.a. The Docker image appears to be based on Debian either bullseye or sid, where these static archives are delivered by postgresql-server-dev-13. CI is based on ubuntu 18.04, which (not surprisingly) delivers it via a package of the same name. One problem is that this package delivers the libraries into /usr/lib/postgresql/13/lib. That's not where pg_config --libdir points -- it points to /usr/lib/x86_64-linux-gnu. And further, /usr/lib/postgresql/13/lib does not contain libpq.a, which is also needed (and PostgreSQL delivers them all three of these to the same directory). So to use this, we would need to specify an additional -L flag during the build, specifically for these environments and hardcoded to that path. They don't seem configurable in the usual ways (pg_config or pkg-config). @luqmana suggests setting LIBRARY_PATH to include them, which seems promising. Basically, I think the ideas are: (1) Modify the Docker image / CI environments to include the archives from these packages and make sure the build can find them. (What's described above.) |
|
In 3498daf, I did modify the Dockerfile to include the package with the static archives, but the Docker build now fails because of missing ldap and gss symbols. For reference, on this system, libpq.so has these dependencies: I didn't run into this on illumos. That's because this Linux build of libpq is built with a lot more options: compared with the illumos one: Since we're linking statically, we have to add these dependencies ourselves. Now, we could modify pq-sys to emit "-l" options for these additional libraries too. But I believe some have different names on illumos, so this gets messy, and it feels increasingly like throwaway work. We'd be making the build system match the (contrived) execution environment when we actually have full control over the execution environment. I looked briefly into how openssl-sys works when building from source. This really happens through openssl-src, which looks like this: It's not awful, but it's also not trivial. It's essentially exposing a Rust library interface around |
|
In light of those issues, I went back to the dynamic linking approach -- see #225 (comment). |
This was #233. If this works out, this will obviate #225 and finally resolve #213.
The Docker and Linux builds both fail because those distros don't ship libpgcommon.a and libpgport.a. Maybe we can build this separately like we do for Clickhouse and CockroachDB and have CI use those.